-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Made Amount more generic. #52
Conversation
Ok(Self::zero()) | ||
} else if 0 <= amount && amount <= MAX_MONEY { | ||
} else if Magnitude::default() <= amount { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you think it would be worth having a trait for these magnitudes? Then we could add associated MIN_MONEY
and MAX_MONEY
constants.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe as a separate PR. For this PR I think it's probably be simpler to not restrict the range of Amount
s allowed by the MASP crate (beyond what is already imposed by the cryptography).
…. Removed ValueSum from bool implementation.
63d83f4
to
d3a4384
Compare
d3a4384
to
4862ae7
Compare
…ueSum. Corrected comments.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might need additional tests/cleanup later
I've been thinking about other approaches to allowing
u64::MAX
notes and eliminating risk of overflow problems. Here's one that came to mind. Specifically, the following changes are made:Amount
generic over the integer type (so it can now bei64
,128
, or perhapsi256
oru256
)Checked*
traits from thenum-traits
library (which is also used in thenamada
repo)i128
to accumulatevalue_balance
sThe benefits of this approach are that:
Amount
type may be easier to reuse from thenamada
crate (if we somehow useTokenChange
as the integer type) and may help to avoid having to writeMaspAmount
(at https://github.com/anoma/namada/blob/ec845c28548269deb5d6ce7fef44aa1275c55d82/shared/src/ledger/masp.rs#L427 which is similar toAmount
)AllowedConversion
can now be backed by ai64
ori32
based type, i.e. it is not forced to use a 128 bit based type because of the requirements onAmount
s in other contexts. Hence space savings.MAX_MONEY
values that are smaller than the range of the underlying integer type are not currently supported here, but it should be doable if it is desired. This is just another approach, maybe some of the ideas here could be used to extend #46 ?